Amendments to the Drawings: 

The attached sheets of drawings include changes to FIGs. 1, 5, 11 and 19. These sheets 
replace the original sheets including FIGs. 1, 5, 11 and 19. In FIG. 1, previously omitted 
reference numeral 120 has been added. In FIG. 5, spelling of "Registry" in element 502 has been 
corrected. In FIG. 11, spelling of "From" at the top of the figure has been corrected. Finally, in 
FIG. 19, spelling of "Executable" in block 1908 has been corrected. 

Attachment: Replacement Sheets 
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REMARKS 

In the non-final Office Action mailed August 9, 2007, claims 1, 4-11, 14-17, 29 and 30 
were rejected under 35 U.S.C. § 102(b) as being anticipated by Mitra et al. (U.S. Patent No. 
7,107,277; hereinafter "Mitra"); claims 1 and 11 were rejected under 35 U.S.C. § 102(e) as being 
anticipated by Winklevoss et al. (U.S. Patent Application Publication No. 2004/0117202; 
hereinafter "Winklevoss"); claim 2 was rejected under 35 U.S.C. § 103(a) as being unpatentable 
over Mitra in view of Admitted Prior Art; claims 3 and 13 were rejected under 35 U.S.C. § 
103(a) as being unpatentable over Mitra in view of Singh et al. (U.S. Patent Application 
Publication No. 2005/0149538; hereinafter "Singh"); claim 12 was rejected under 35 U.S.C. § 
103(a) as being unpatentable over Mitra in view of "Siebel eService Administration Guide 
Addendum For Industry Applications - Version 7.5.3" (hereinafter "Seibel 7"); and claims 1-17, 
29 and 30 were rejected under 35 U.S.C. § 101 as being directed to unpatentable subject matter; 
and claims 1-10, 29 and 30 were objected to for various informalities. Both the specification and 
drawings were objected to for various informalities. Applicants respectfully traverse and request 
reconsideration. 

The drawings stand objected to for various informalities. As noted above, replacement 
sheets are submitted herewith for FIGs. 1,5, 11 and 19 to correct the informalities noted in the 
Office Action as well as other informalities noted by Applicants. These corrections do not add 
new subject matter. As such, Applicants respectfully submit that the drawings are in suitable 
condition to support allowance. 

The specification stands objected to for various informalities. By way of amendment 
above, the various informalities in the specification noted in the Office Action, as well as other 
informalities noted by Applicants, have been corrected. These corrections do not add new 
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subject matter. As such, Applicants respectfully submit that the specification is in suitable 
condition to support allowance. 

Claims 1-10, 29 and 30 stand objected to for various informalities. By way of 
amendment above, the various informalities in claims 1-10, 29 and 30 noted in the Office Action, 
as well as other informalities noted by Applicants, have been corrected. These corrections do not 
add new subject matter. As such, Applicants respectfully submit that claims 1-10, 29 and 30 are 
in condition for allowance. 

Claims 1-17, 29 and 30 stand rejected under 35 U.S.C. § 101 as being directed to 
unpatentable subject matter. While Applicants traverse the substance of the rejection under 
Section 101, Applicants further note that claims 1 and 1 1 have been amended, as suggested in the 
Office Action, to recite that the claimed procedural computation engine and rating service are 
"embodied in a hardware computing system". For this reason, Applicants respectfully submit 
that independent claims 1 and 11, as well as their respective dependent claims 2-10, 12-17, 29 
and 30, recite patentable subject matter and are therefore in suitable condition for allowance. 

Claims 1, 4-11, 14-17, 29 and 30 stand rejected under 35 U.S.C. § 102(b) as being 
anticipated by Mitra. Mitra teaches a "calculation engine 200" that takes both "input data 
sources 202" and "calculation specifications 204" as inputs and subsequently provides 
"calculation results 206" as output. (FIG. 2) As noted in col. 7, lines 9-10 of Mitra, the input 
calculation specification 204 "may be defined via [an] XML schema." However, Mitra is 
completely silent as to how such an XML schema could be derived. Operating on those two 
input types (data sources 202 and calculation specifications 204), the calculation engine 200 
outputs the results 206 that appear to be the desired calculation results, e.g., calculation of 
portfolio risk. (col. 6, lines 36-54) Thus, the specific calculations performed by the calculation 
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engine 200 appear to be based strictly on input calculation specifications 204, i.e., the input 
XML schema, and Mitra is otherwise silent with respect to how the XML schema is employed to 
generate the calculation results 206. 

In contrast, as presently recited in claim 1, a graphical user interface is used to create at 
least one procedural computational schema that is subsequently interpreted by a parser, the 
output of which is used by a compilation component to generate an executable model, i.e., 
executable code. Applicant is unable to find any teachings in Mitra that a graphical user 
interface is employed to create Mitra 's calculation specifications schemas. Indeed, the cited 
portions of Mitra in this regard (FIG. 2; col. 6, lines 36-67; col. 7, lines 8-31; and col. 9, lines 9- 
27) fail to make any mention as to how the various formulae described therein are captured in the 
input schema. 

Furthermore, with regard to both the claimed parser and compilation component, the 
cited teachings of Mitra in this regard fail to make any mention of such elements. As recited in 
claim 1, the parser interprets the schemas created by the graphical user interface, and the parser's 
resulting output is further operated upon by the compilation component to create executable 
models. The cited portions of Mitra concerning the claimed parser and compilation component 
at best teach that Mitra' s calculation engine 200 operates upon the input calculation 
specifications 204 (i.e., Mitra' s "schema"), but is otherwise silent with regard to how the 
calculation engine 200 operates. Applicants note that Mitra's dependency graphs of FIGs. 3-5 
(and associated text: col. 10, line 60 - col. 12, line 64) illustrate that Mitra's calculation engine 
200 attempts to build such dependency graphs when performing the desired calculations in the 
most efficient manner possible. However, no mention is made that such dependency graphs 
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(equated, apparently, in the Office Action with the claimed "hierarchical node-structuring") are 
used to generate executable models, i.e., executable code, as presently claimed. 

For at least the reasons given above, Applicants respectfully submit that Mitra fails to 
teach the use of a graphical user interface for the creation of schemas that, in turn, may be 
subsequently processed by a parser and compilation component to create executable models, as 
recited in instant claim 1. As such, Applicants respectfully submit that claim 1 is in suitable 
condition for allowance. 

Claims 2-10 are dependent upon, and therefore incorporate the limitations of claim 1. 
Thus, to the extent that claim 1 is not anticipated by Mitra, Applicants respectfully submit that 
claims 2-10 are likewise in suitable condition for allowance. Furthermore, the various dependent 
claims 2-10 recite additional patentable subject matter. 

With regard to claim 4, it is asserted that Mitra teaches the claimed compilation 
component including a lexical scanner and code generator. However, the cited portions of Mitra 
(FIG. 2; col. 7, lines 8-31; col. 6, lines 36-46) fail to make any mention of such elements, or any 
other elements capable of generating executable code. Once again, while the cited portions 
indicate that Mitra' s calculation engine 200 can perform calculations based on the input 
calculation specifications 204, no instruction is provided as to how this is done, much less that 
the input calculation specifications 204 are parsed and compiled in order to generate an 
executable model. 

With regard to claim 10, reference is made to "the processing application" being able to 
process and save data in XML form. Reference to claim 2, from which claim 10 depends, 
reveals that the claimed "processing application" is the graphical user interface in the form of an 
"interactive spreadsheet processing application." As noted above, Mitra is completely silent with 
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regard to a graphical user interface and, by necessity, is likewise silent concerning the claimed 
processing application. 

With regard to claims 29 and 30, to the extent that Mitra fails to teach the claimed 
compilation component, the further refinements of the compilation component presented in 
claims 29 and 30 are likewise not taught by Mitra. Indeed, Applicants can find no reference to 
the claimed "block translator for scooping variables" (claim 29) or the claimed "loop constructs" 
(claim 30). 

With regard to claim 11, Applicants note that the various claimed elements discussed 
above, e.g., the graphical user interface, the parser and compilation component, are likewise 
recited in claim 11. Thus, Applicants respectfully submit that claim 11 is also allowable over 
Mitra for the reasons provided above. Additionally, Applicants note that claim 1 1 recites an 
interface application that is used, in conjunction with a knowledgebase configurator, to submit 
user service requests in which parameters in the service request allow the configurator to select 
an appropriate rate model from the server component of the procedural computation engine, 
which rate model is subsequently executed to provide the desired rating results. Despite the 
citations to the various teaching of Mitra, Applicants respectfully submit that Mitra fails to teach 
these claimed limitations. 

For example, with regard to the claimed knowledgebase configurator, the cited portions 
of Mitra merely refer to the fact that Mitra's calculation engine 200 may generate dependency 
graphs when implementing the desired calculations. No reference is made to any device (i.e., the 
claimed knowledgebase configurator) apart from the calculation engine 200 (i.e., the claimed 
procedural computation engine), much less any such device that is used to process service 
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requests and select rating models (i.e., executable code) from the procedural computation 
engine's server component. 

For at least these reasons, Applicants respectfully submit that Mitra fails to anticipate 
claim 11, which claim is therefore in suitable condition for allowance. 

Claims 12-17 are dependent upon, and therefore incorporate, the limitations of claim 11. 
Thus, to the extent that claim 1 1 is not anticipated by Mitra, Applicants respectfully submit that 
claims 12-17 are likewise in suitable condition for allowance. Furthermore, the various 
dependent claims 12-17 recite additional patentable subject matter. 

Claims 1 and 11 stand rejected under 35 U.S.C. § 102(e) as being anticipated by 
Winklevoss. Winklevoss describes a system in which an "expression language" is provided 
which allows a novice programmer to generate provisions of a defined benefit (DB) retirement 
plan. (para. 0008) Using a suitable data processing system 135, a user can create the DB plans 
using the expression language, which plans are thereafter stored in a repository 125. A 
calculation module 120 may access the DB plans stored in the repository 125 as needed, for 
example, is response to requests concerning plan benefits, (para. 0054-0061). 

As in the case of the Mitra reference, Applicants respectfully submit that, contrary to the 
assertions in the Office Action, Winklevoss fails to teach the claimed parser and compilation 
component. While the various teaching of Winklevoss indicate that the provisions of the DB 
plans are created using the expression language and subsequently stored in the repository 125, 
Applicants can find no teachings that the provisions of the DB plans are subjected to processing 
by a parser and compilation component to produce executable models. That is, Winklevoss is 
silent with regard to whether the DB plans provisions are executed by the calculation module 
120 in the form of a compiled, executable program or through some other means, i.e., through 
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the use of an interpreter. To the extent that Winklevoss thus fails to teach the presently claimed 
parser and compilation component, Applicants respectfully submit that Winklevoss fails to 
anticipate claims 1 and 1 1 . 

Claim 2 stands rejected under 35 U.S.C. § 103(a) as being unpatentable over Mitra in 
view of Admitted Prior Art. In particular, it is acknowledged that Mitra fails to teach a graphical 
user interface comprising an interactive spreadsheet processing application. It is noted, however, 
that the use of spreadsheet applications for performing complex business applications is well 
known in the art. (instant application, page 3, lines 14-26) Thus, it is concluded in the Office 
Action, it would have been obvious to modify the teachings of Mitra to incorporate the 
spreadsheet application of the APA to the extent that the APA suggests the desirability of using 
such spreadsheet applications. 

Applicants note the various deficiencies of Mitra noted above relative to claim 1, 
particularly with respect to the claimed parser and compilation components, which limitations 
are incorporated into claim 2 by virtue of its dependence on claim 1 . To the extent that the APA 
fails to overcome these deficiencies of Mitra, Applicant respectfully submits that Mitra in view 
of the APA fails to establish prima facie obviousness of claim 2, which claim is therefore in 
suitable condition for allowance. 

Claims 3 and 13 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Mitra in view of Singh. In particular, it is acknowledged that Mitra fails to teach the parser being 
able to read XML and produce output in Java Document Object Model (JDOM) structure. To 
this end, it is noted that Singh teaches the use of JDOM structures when implementing "logical 
data models". (Singh, para. 0122-0124) Thus, it is concluded in the Office Action, it would 
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have been obvious to modify the teachings of Mitra to incorporate the JDOM teachings of Singh 
to the extent that the Singh demonstrates the advantages of using JDOM structures. 

Applicants note the various deficiencies of Mitra noted above relative to claims 1 and 11, 
particularly with respect to the claimed parser and compilation components, which limitations 
are incorporated into claims 3 and 13 by virtue of their dependence on claims 1 and 11, 
respectively. To the extent that the teachings of Singh fail to overcome these deficiencies of 
Mitra, Applicant respectfully submits that Mitra in view of Singh fails to establish prima facie 
obviousness of claims 3 and 13, which claims are therefore in suitable condition for allowance. 

Finally, claim 12 stands rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Mitra in view of Scibcl 7. In particular, it is acknowledged that Mitra fails to teach the "software 
interface application" being an insurance application suite. To this end, it is noted that Seibel 7 
teaches an insurance application suite. (Seibel 7, p. 57 et seq.) Thus, it is concluded in the 
Office Action, it would have been obvious to modify the teachings of Mitra to incorporate the 
insurance application suite of Seibel 7 in order to provide customers insurance-related e-services 
as suggested by Seibel 7. 

Applicants note the various deficiencies of Mitra noted above relative to claim 11, 
particularly with respect to the claimed parser and compilation components, which limitations 
are incorporated into claim 12 by virtue of its dependence on claim 11. To the extent that Seibel 
7 fails to overcome these deficiencies of Mitra, Applicant respectfully submits that Mitra in view 
of the Seibel 7 fails to establish prima facie obviousness of claim 12, which claim is therefore in 
suitable condition for allowance. 
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It is believed that all of the stated grounds of rejection have been properly traversed, 
accommodated, or rendered moot. Applicants therefore respectfully requests reconsideration and 
withdrawal all presently outstanding rejections. Thus, prompt and favorable consideration of this 
response is respectfully requested. If it is believed that personal communication will expedite 
prosecution of this application, Applicant's undersigned representative may be contacted at the 
number below. 

Respectfully submitted, 

Date: November 8. 2007 By: ( - J ~ Jt ^- ?■ 

Christopher P. Moreno 
Registration No. 38,566 

Vedder, Price, Kaufman & Kammholz, P.C. 
222 N. LaSalle Street 
Chicago, Illinois 60601 
Phone: (312)609-7842 
Fax: (312)609-5005 
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APPENDIX 

1 . Four (4) drawing Replacement Sheets 



CHICAGO/#1712588.1 



22 



